Personal information about users, as well as the mechanism to log onto computers, is typically hosted within central repositories. Each repository is called a domain or realm that binds each participating user to data within the repository. For example, when a user intends to obtain data from a computer system in a certain domain, he will typically have to authenticate himself and possibly also have his authorization verified which involves an access to the respective repository.
However, in larger organizations there are usually multiple domains. As a result, a user, which has already authenticated (and authorized) himself in a first domain and now wants to perform or access resources owned by a second domain, needs again to be authenticated in the second domain. This is particularly a problem, if the first and second domain are heterogeneous, i.e. if different hardware and/or software is used.
Kerberos is one system known in the prior art that provides a trust relationship when the first and second domain reside on some heterogeneous platforms. However, there are many practical instances where this approach cannot be used on heterogeneous systems (e.g. a Kerberos solution is unavailable for a platform or existing security systems and/or applications cannot easily be modified to fit the Kerberos approach). Other ways to address these difficulties to some extent are known from the EP 1 035 462 and the EP 1 650 923.
In particular for domains that are truly heterogeneous, i.e. there is no communication path defined between domains that allows to set up a trust relationship, one approach known in the prior art is to use some form of user identity mapping. When a user, which has already logged onto the first domain, intends to access resources from the second domain, his user id (for example “John Doe”) of the first domain is mapped to another user id (for example “jdoe”) which meets the specific requirements of the security system of the second domain. This mapping process is typically performed by an Identity Management System that accesses a database for this purpose.
However, the identity data that is stored in the database and passed on from the database to the application that requires the mapping is automatically trusted and cannot be checked at runtime by neither the application nor the user. In other words, there is no verification of the identity mapping information by either the user or the application once it has been stored. This presents a possible security gap that could be exploited by a malicious attack, if, for example, the identity mapping were modified to “hijack” another identity at another domain. More importantly, neither the user nor the application would even be able to detect that such an attack has occurred.
Correspondingly, improvements in user mappings between domains are desirable.